ICTSC Tech Blog

ICTSC2020 インフラ解説 仮想化基盤編

ICTSC2020 Tips サーバー関連

humstackについて

https://github.com/ophum/humstack

主な仕組み

今回作成したhumstackはkubernetesのようにリソース情報を保存するapiserverとそのapiで取得する情報を元にリソースを展開するagent(kubernetesで言うところのcontrollerやoperator)によって構成されています。
humstackでは主に以下のagentが動作しています。

  • VirtualMachineAgent
    • 仮想マシンを作成・削除します。
  • BlockStorageAgent
    • 仮想ディスクを作成・削除します。
  • NodeNetworkAgent
    • 仮想ネットワーク(Linux Bridgeやvlanインターフェース)を作成・削除します。

humstack dashboardについて

https://github.com/ophum/humstack-dashboard
humstackでは操作する方法としてWebUIであるhumstack dashboardを容易し問題の作成に利用しました。

UIから問題で使用するVMやディスクネットワークを定義できます。

dashboardでは、問題の作成だけでなくチーム毎の展開を行うことが出来ます。
上記の定義を元に各チーム毎に展開できます。ICTSCではノードの障害が起きたときに公平性が損なわれる可能性を減らすため、1つの問題は1つのノード上で動作させます。そのため、dashboardでは展開先のノードを指定できるようにしています。

humstackのCeph利用について

qemuの起動オプションで以下の指定をすることで、rbdのディスクを接続することが出来ます。

-drive file=rbd:image-name

ceph/go-cephを利用してcephイメージの作成・削除を実装しました。
問題VMの仮想ディスクのベースイメージ(問題を展開する際に元にするイメージ)化を行う際にスナップショットを作成し、スナップショットを利用して問題の仮想ディスクを作成することでディスク使用量を減らすことが出来ました。
@onokatioがhumstackにスナップショットの作成などの機能を実装してくれました。

ベースイメージが5GB, 5VMの場合
※ αは起動後に増える使用量

1チーム使用量20チーム使用量
スナップショット未使用25GB + α500GB + α
スナップショット使用25GB + α25GB + α

Cephクラスタについて

分散ストレージの一種で、複数のマシンでストレージデバイスを管理し、多重に保管することでデータの完全性を高めることができます。
今回は問題VMのブロックストレージを保管する目的で使用しました。

Cephの特徴

  • 各HDD/SSDにOSDと呼ばれるサービスが動作し、モニターと呼ばれるサービスがどのOSDにどのデータが置いてあるかを管理する
  • モニターは冗長構成のためある程度生き残っていれば読み書きに問題がない
  • データはデフォルトで3OSDに複製されるので、ある程度生き残っていれば読み書きに問題がない
  • NFSやS3互換API、RBDなどのインターフェイスでデータを操作できる

使われ方

humstackの章で先述したように、「RBD」と呼ばれる、仮想的なブロックストレージを複数作りCephに保存できる仕組みを採用しました。

またスナップショット機能と呼ばれる、親となるブロックストレージからCopy on Write方式で子となるブロックストレージを生成できる機能を利用しました。データ変更・削除のみが子に保存され、それ以外のデータ読み込みは親へとパススルーされます。

これにより、問題のブロックストレージを各チーム分コピーしても、物理ディスク使用量は数倍にはならず、実際には各チームごとの変化分のみデータが増加する程度に抑えられました。
今までICTSCでは電源やメモリ、ストレージが足りない問題が多々ありましたが、今回はCephスナップショットの採用で大変余裕を持ったストレージ設計が行えました。

構成

以下の構成を行いました。

  • SSD 1TB x 6個(それぞれ別サーバーに配置)
    • 主にVMのブロックストレージ系をこのSSDからなるプールに保管しました
  • HDD 2TB x 3個(それぞれ別サーバーに配置)
    • バックアップや雑多な目的に利用しました
  • モニター x 8サービス(それぞれ別サーバーに配置)
    • 意思決定には奇数台である必要があるため、実際には常に1台はスタンバイ状態でした。
  • マネージャー x 8サービス(それぞれ別サーバーに配置)
    • OSDやモニターの死活監視、スケール、更新や、ダッシュボードを提供していました。

性能

ホットステージ期間での負荷テストでは、CPUとストレージ帯域を100%まで使い切る様子が確認できました。
（正確なメトリクスが残っていないので概算ですが）SSDのみのプールの場合、最大IOPS・最大速度がSSD一つとより少し低いぐらいの性能が出ています。
各OSDへのレプリカがライトバック方式で行われていること、ネットワークが10Gでありボトルネックにならなかったことなどが起因して、出せる最大スペックでのストレージ性能が出ていたと考えられます。
結果的に、問題VMの全展開も数分程度に収まるようになりました。

また、ブロックストレージ以外にも雑多なデータ保管にCephを使いました。その際にはCephをLinuxにファイルシステムとしてマウントして利用しましたが、ローカルのストレージと同じ様に振る舞い、ファイルの故障なども起こりませんでした。

評価

構築中には様々な障害がありましたが、本戦期間中に大規模な問題なども起こらず、結果としてCephをストレージとして採用して成功たったと思います。
正直ここまでの速度が出るとは思わなかったので、予想以上の働きをしてくれました。